1 Posicionamiento Y LíMites Del Protocolo

Capítulo 1: Posicionamiento y Límites del Protocolo

1.1 Responsabilidad de CAP en el Ecosistema iFay

El Control Authority Protocol (CAP) asume una responsabilidad central única y claramente definida dentro del ecosistema iFay: verificar si un Fay (iFay o coFay) ha sido autorizado por su anfitrión humano (Natural_Person) o puesto oficial (Official_Post) para acceder legítimamente a los recursos del terminal (Terminal_Resource).

En concreto, el protocolo CAP es responsable de las siguientes tareas:

• Verificación de autorización: Cuando un Fay solicita acceso a recursos de software o hardware de un terminal, el protocolo CAP verifica si las credenciales de autorización presentadas (Authorization_Descriptor o Trusted_Ticket) son legítimas, válidas y no han sido revocadas. Por ejemplo, cuando el iFay de un usuario quiere abrir la cámara del teléfono para tomar una foto, el terminal debe verificar primero que dicho iFay ha sido efectivamente autorizado por el usuario para usar la cámara
• Gestión de sesiones: Establecimiento de sesiones de control (Sessions) para los Fays que han superado la verificación de autorización, y gestión del ciclo de vida completo de dichas sesiones. Por ejemplo, después de que un iFay obtiene autorización y comienza a operar el navegador, todo el proceso desde abrir hasta cerrar el navegador constituye una sesión de control completa
• Coordinación de control: Coordinación de la asignación y transferencia del control sobre los recursos del terminal entre múltiples Fays o entre Fays y usuarios humanos. Por ejemplo, un dron controlado manualmente necesita ser transferido a un Fay para vuelo autónomo; o dos iFays necesitan usar la misma impresora sucesivamente
• Control de acceso escalonado a recursos: Gestión escalonada del acceso a recursos por tipo de operación (lectura, escritura, ejecución, configuración). Por ejemplo, un iFay que lee datos del sensor de temperatura solo necesita permiso read, mientras que modificar la configuración de temperatura del aire acondicionado requiere permiso write
• Detección de actividad: Monitorización del estado de actividad de las sesiones activas y recuperación oportuna de los recursos ocupados por sesiones expiradas. Por ejemplo, después de que un iFay pierde la conexión debido a una interrupción de red, el terminal detecta un timeout de heartbeat y libera automáticamente el control de la cámara ocupado por ese iFay, evitando que los recursos queden bloqueados indefinidamente por « sesiones zombi »

El protocolo CAP es el puente clave entre los agentes inteligentes y los recursos del terminal en el ecosistema iFay — no se preocupa por quién es un Fay ni qué puede hacer, sino únicamente por si un Fay está autorizado para realizar una acción determinada.

1.2 Responsabilidades Fuera del Ámbito de CAP

Para garantizar límites de responsabilidad claros, el protocolo CAP explícitamente no es responsable de los siguientes aspectos:

1. Creación y gestión de la identidad de Fay: El registro de entidades Fay, la asignación de identificadores de identidad, el mantenimiento de atributos de identidad y otras tareas son responsabilidad del subsistema de gestión de identidades del ecosistema iFay. CAP solo consume información de identidad para la verificación de autorización y no participa en el proceso de creación y gestión de identidades. Por ejemplo, "cómo se llama este iFay y a quién pertenece" lo determina el sistema de gestión de identidades; CAP solo se preocupa por "si este iFay está autorizado a usar la cámara"
2. Capacidades de razonamiento inteligente de los Fays: Cómo un Fay comprende las intenciones del usuario, planifica los pasos de operación y realiza razonamiento inteligente pertenece a la capa de inteligencia del propio Fay y no tiene relación con el protocolo CAP. CAP no hace suposiciones ni impone requisitos sobre el nivel de inteligencia de un Fay. Por ejemplo, un iFay decide primero abrir el navegador y luego buscar billetes de avión — este proceso de decisión no tiene relación con CAP; CAP solo realiza la verificación de autorización cuando el iFay efectivamente solicita abrir el navegador
3. Lógica de negocio específica de los recursos del terminal: Cómo el software del terminal responde a los comandos de operación y cómo el hardware ejecuta funciones específicas es responsabilidad de los propios recursos del terminal. CAP solo es responsable de la verificación de autorización y el control de acceso, y no interviene en el procesamiento de negocio específico de los recursos. Por ejemplo, cómo la impresora formatea las páginas o qué cartucho de tinta usa para imprimir son lógica de negocio propia de la impresora; CAP solo verifica si el iFay tiene derecho a usar la impresora
4. Implementación de protocolos de comunicación de red: CAP define el flujo lógico de verificación de autorización y los formatos de mensaje, pero no prescribe la implementación específica de los protocolos de transporte de red subyacentes. Por ejemplo, si el terminal se comunica con iFay_Runtime mediante WebSocket o gRPC, CAP no impone restricciones
5. Mecanismos de seguridad internos del sistema operativo del terminal: Los mecanismos propios del sistema operativo como la gestión de permisos de usuario, el aislamiento en sandbox y la seguridad de procesos no están dentro del ámbito de CAP. CAP colabora con el sistema operativo a través de interfaces de integración. Por ejemplo, el mecanismo de sandbox de aplicaciones de Android es gestionado por Android; CAP emite instrucciones de control de acceso a través de las interfaces proporcionadas por Android

1.3 Relación con Otros Subproyectos

El protocolo CAP tiene relaciones de interacción claramente definidas con los siguientes subproyectos dentro del ecosistema iFay:

Subproyecto	Descripción de la Relación	Límite de Interacción
iFay_Runtime	Principal invocador de CAP. iFay_Runtime es responsable de la gestión del ciclo de vida y la planificación de las instancias Fay. Cuando un Fay necesita acceder a recursos del terminal, iFay_Runtime inicia la solicitud de control en su nombre	iFay_Runtime → CAP: Inicia solicitud de verificación de autorización; CAP → iFay_Runtime: Devuelve resultado de verificación e información de sesión
Registration_Authority	Dependencia de infraestructura de confianza de CAP. Registration_Authority es responsable del registro de hardware, software y sistemas operativos de terminales, y distribuye claves de verificación (Verification_Key) a los terminales	Registration_Authority → Terminal: Distribuye Verification_Key; El terminal usa Verification_Key para verificar la firma del Authorization_Descriptor
Descriptor_Issuer	Fuente de credenciales de autorización de CAP. Descriptor_Issuer, tras ser autorizado por Natural_Person u Official_Post, es responsable de generar y emitir Authorization_Descriptors	Descriptor_Issuer → Fay: Emite Authorization_Descriptor; Fay presenta Authorization_Descriptor al terminal para iniciar solicitud de acceso
Subsistema de gestión de identidades	Fuente de información de identidad de CAP. CAP necesita referenciar el identificador de identidad del Fay durante el proceso de verificación de autorización, pero no participa en la creación y gestión de identidades	Gestión de identidades → CAP: Proporciona información de identificación del Fay (dependencia unidireccional)

El principio de diseño del protocolo CAP es mantener la cohesión de sus propias responsabilidades: solo realizar verificación de autorización y gestión de control, dejando la gestión de identidades, el razonamiento inteligente, la lógica de negocio de recursos y otras responsabilidades a otros subproyectos del ecosistema.

1.4 Escenarios de Aplicación

El escenario de aplicación central del protocolo CAP es: iFay asume el control del terminal de su anfitrión humano, utilizando el software del terminal y accediendo al hardware del terminal como lo haría un humano.

En este escenario, el anfitrión humano (Natural_Person) otorga el control parcial o total de sus dispositivos terminales a su iFay, para que iFay opere en su nombre el software cliente del terminal (como navegadores, clientes de correo electrónico, software de oficina) y los dispositivos de hardware (como cámaras, micrófonos, dispositivos de almacenamiento). El protocolo CAP garantiza que durante este proceso:

• Legitimidad de la autorización: El terminal puede verificar que el iFay efectivamente ha obtenido la autorización de su anfitrión humano, y no se trata de un acceso no autorizado. Por ejemplo, si el iFay de Zhang San intenta operar el portátil de Li Si, el terminal rechazará el acceso por la falta de credenciales de autorización emitidas por Li Si
• Disponibilidad sin conexión: Incluso si el terminal está sin conexión, siempre que el iFay posea un Authorization_Descriptor válido, puede acceder legítimamente a los recursos autorizados. Por ejemplo, cuando un usuario activa el modo avión en un vuelo, su iFay puede seguir operando el software de oficina en el portátil gracias al archivo de autorización sin conexión almacenado previamente
• Coordinación multipartita: Cuando múltiples Fays o Fays y usuarios humanos necesitan acceder simultáneamente al mismo recurso del terminal, el protocolo CAP proporciona capacidades de transferencia de control y gestión de modos de acceso a recursos. Por ejemplo, un usuario está tomando fotos con su teléfono cuando el iFay también necesita usar la cámara para escanear un documento — el protocolo CAP coordina el orden de uso entre ambos
• Seguridad y control: Todas las operaciones de verificación de autorización y acceso a recursos pueden ser auditadas, y la autorización puede ser revocada en cualquier momento. Por ejemplo, si un usuario descubre un comportamiento anormal de su iFay, puede revocar inmediatamente su autorización para todos los recursos del terminal, y las sesiones activas del iFay serán terminadas forzosamente

El mismo marco de protocolo también se aplica al escenario de coFay — entidades Fay colaborativas que, tras ser autorizadas por un puesto oficial (Official_Post), asumen el control de dispositivos terminales organizacionales para ejecutar tareas colaborativas.

1.5 Principios de Diseño Fundamentales

El protocolo CAP sigue el principio de diseño fundamental de sin conexión como prioridad, en línea como complemento.

La autorización sin conexión (Authorization_Descriptor) es el mecanismo central. Los dispositivos terminales no deberían privar completamente al Fay de su derecho de control debido a la falta de disponibilidad de red. Si un Fay ha obtenido previamente la autorización de su anfitrión humano, esta relación de autorización debería almacenarse en forma de archivo cifrado localmente en el terminal, permitiendo que el terminal complete la verificación de autorización de forma independiente en estado sin conexión. Authorization_Descriptor es la implementación concreta de este concepto — es un archivo cifrado de descripción de autorización almacenado localmente en el terminal, que contiene el alcance de los recursos, los tipos de permisos y el período de validez para los que el Fay está autorizado. El terminal puede completar la verificación a través del Descriptor_Validator local sin necesidad de conexión a la red.

El ticket en línea (Trusted_Ticket) es el mecanismo complementario. En entornos conectados, Trusted_Ticket proporciona capacidades de emisión de autorización en tiempo real y consulta del estado de revocación, compensando las deficiencias de la autorización sin conexión en cuanto a oportunidad y velocidad de respuesta ante revocaciones. Cuando los servicios en línea están disponibles, el terminal puede obtener el estado de autorización más reciente a través de Trusted_Ticket; cuando los servicios en línea no están disponibles, el terminal retrocede automáticamente a la verificación local de Authorization_Descriptor, asegurando que el servicio no se interrumpa.

Las consideraciones centrales de este principio de diseño son:

• Disponibilidad como prioridad: La interrupción de la red no debería ser una razón para que el Fay no pueda trabajar; la autorización sin conexión garantiza la disponibilidad básica. Por ejemplo, cuando la señal del teléfono de un usuario se interrumpe en el metro, el iFay puede seguir operando las aplicaciones sin conexión del teléfono gracias al archivo de autorización local
• Mejora de la seguridad: El ticket en línea proporciona garantías de seguridad en tiempo real más fuertes cuando hay conexión, incluyendo revocación inmediata y ajuste dinámico de permisos
• Degradación progresiva: La transición de en línea a sin conexión es fluida y no causa una interrupción repentina del servicio. Los Trusted_Tickets emitidos en línea pueden convertirse al formato local de Authorization_Descriptor para uso sin conexión. Por ejemplo, un usuario autoriza a su iFay a usar la cámara mediante un ticket en línea bajo Wi-Fi; cuando el usuario sale de la zona de cobertura Wi-Fi, la autorización se degrada automáticamente al modo sin conexión y sigue siendo efectiva